웹 서비스는 어떻게 발전하는가

1. WAS(tomcat) - DB 구조 서버 한대에서 static resource등 다 함. 문제: Scale Up 만으로는 처리에 한계가 생김

2. WEB - WAS - DB 구조 정적 컨텐츠 / 동적 컨텐츠 구분 Web server(nginx) / Web Application Server(node.js) 문제: 무정지 배포가 안됨. WAS 부담을 줄이고 싶음 어플리케이션 오류가 서비스 장애로 이어짐

해결: Scale out, Load Balancing

웹서버에서 Load Balancing하는게 제일 쉬운 방법 Apache: process + thread, 설정이 복잡 Nginx: event driven, 설정이 체계적, 빠른 응답

3. WEB, WAS|WAS DB WAS가 두개 이상! WAS에서 쓰는 코드는 싱글턴/세션 사용을 자제해야함. 같은 설정값을 보장하기 위해서 문제: Web에 부하가 생김, Web덩치가 커져서 쉽게 끄고 키고 할 수 없음(서비스 영향) 해결: Web scale out, 전문 LB 장비 설정 Domain 주소를 이용한 분산 방식(효율은 별로임)

LB 방식: Round Robin / Least Conn. 성능이 비슷할 때 / 리소스 스펙이 불명확할 때

LB에서 중요한것 Health Check, L4 LB / L7 LB OSI처리 가능 계층으로 나뉘는 방식 L4는 TCP까지, L7은 HTTP 요청단위까지 L2 서버만 살아있는지 확인 L4 포트 접속, 서비스 동작까지 확인 L7 실제 어플리케이션 동작하는지 확인

4. LB + WEB|WEB + WAS|WAS + DB 웹도 순서대로 재시작 로그보기가 점점 어려워진다. 문제: DB에 부하가 걸리기 시작한다. 해결: DB도 scale out 한다.

서버는 걍 데이터를 전달해주고 처리하는거라 scale out 하기 쉬움 DB는 저장 상태 관리 때문에 분리가 어렵다. 방식: Active Standby / Read Replica

1. 하나가 계속 살아있고, health check 실패시에 standby 가 작동 둘다 복제하는 과정은 필요하긴함
2. Read에 대해서만 DB 여러개 여러 서버 요청을 여러 DB에 어떻게 동기화시킬건지가 어려움

방법: 두가지

1. Write Ahead Log 로그를 쌓다가 두번째 서버로 보내서 싱크를 맞춘다.

2. Streaming agent가 레코드 단위로 계속 보내줌 (좀 더 sync맞출 확률이 높은데 부하가 큼)

Isolation Level: 업데이트 도중 read가 발생하면? 사본에서 읽냐 새로 읽냐? 데이터 정합성 해결 보통 select가 insert/ update/delete 와 연관 없도록 짠다

5. LB + WEB|WEB + WAS|WAS + DB|DB 문제: DB연결이 어려움. 해결: DB 연결에 proxy

이제 기본적인 구성완성

6. 그외 할것

• Redis / kafka/ rabbitMQ 등 메시지 큐 사용해서 내부 시스템간 요청을 빠르게 최적화
  • 🤔메세지큐 서버를 두면 오버헤드가 생길텐데 왜 빨라짐?
• 데이터 직접 라우팅 설정 연결
• 데이터 센터를 지역적으로 나누어두기
• 백업 hot backup / cold backup
• 보안
• 로그 중앙화